lxc: Prevent accept-certificate flag when using trust token #14149
Conversation
MusicDin
force-pushed
the
fix/accept-rem-cert
branch
3 times, most recently
from
e78acd9
to
c611894
Compare
Signed-off-by: Din Music <[email protected]>
If a remote is added, and then removed from the local config (lxc remote delete) and the certificate remains trusted on the remote server, when remote is added again it will fail because it is already trusted. Signed-off-by: Din Music <[email protected]>
Signed-off-by: Din Music <[email protected]>
Signed-off-by: Din Music <[email protected]>
Signed-off-by: Din Music <[email protected]>
Signed-off-by: Din Music <[email protected]>
Signed-off-by: Din Music <[email protected]>
Signed-off-by: Din Music <[email protected]>
Signed-off-by: Din Music <[email protected]>
MusicDin
force-pushed
the
fix/accept-rem-cert
branch
from
c611894
to
639991a
Compare
There was a problem hiding this comment.
Please can you add more detail to the commit message explaining what you fixed.
There was a problem hiding this comment.
If a remote is added, and then removed from the local config (lxc remote delete)
and the certificate remains trusted on the remote server, when remote is added
again it will fail because it is already trusted.
Is this the current state now and what you've fixed, or what you are changing it to be?
I struggled to understand the change here.
There was a problem hiding this comment.
Because:
when remote is added again it will fail because it is already trusted.
Sounds like the wrong behaviour to me, so wanted to understand if this is new or what is being fixed?
There was a problem hiding this comment.
This is the current behavior. If remote is removed, and readded, it will fail when trying to add client certificate into remote's trust store, because it is already present there - failing with Client is already trusted error, and remote not being added.
IMO, we should instead just continue and add the remote.
Example of current behaviour (LXD running in a VM v2 is our remote server):
$ lxc ls
+------+---------+------------------------+-------------------------------------------------+-----------------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+------+---------+------------------------+-------------------------------------------------+-----------------+-----------+
| v2 | RUNNING | 10.70.164.239 (enp5s0) | fd42:2bf4:ef35:8266:216:3eff:fea8:9da4 (enp5s0) | VIRTUAL-MACHINE | 0 |
+------+---------+------------------------+-------------------------------------------------+-----------------+-----------+
# Add the remote (initially).
$ token=$(lxc exec v2 -- lxc config trust add --name test --quiet)
$ lxc remote add test $token
# Remove the remote.
$ lxc remote rm test
# Add the remote (again). The client certificate is already present in remote's trust store.
$ token=$(lxc exec v2 -- lxc config trust add --name test --quiet)
$ lxc remote add test $token
Error: Failed to create certificate: Client is already trustedThere was a problem hiding this comment.
Does lxc remote add test work after doing lxc remote rm test?
There was a problem hiding this comment.
Yes, if target URL is specified:
lxc remote add 10.70.164.239
# or
lxc remote add test 10.70.164.239When token is used, the address is extracted from the token itself (if specific URL is not provided), so it should work even when token is provided.
There was a problem hiding this comment.
Got you. Will the new token still get expired once its used (even though its not really used)?
There was a problem hiding this comment.
No, the token is not consumed.
There was a problem hiding this comment.
Should it not be? From the user's PoV we've used it.
There was a problem hiding this comment.
Yes, I think that makes sense. Will fix that.
| @@ -322,6 +329,11 @@ func (c *cmdRemoteAdd) run(cmd *cobra.Command, args []string) error { | |||
| return errors.New(i18n.G("Trust token cannot be used for public remotes")) | |||
| } | |||
|
|
|||
| // Certificate cannot be blindly accepted when using a trust token. | |||
There was a problem hiding this comment.
Please can you update the comment to explain the why of this statement.
| rawToken, err := shared.CertificateTokenDecode(addr) | ||
| if err == nil { | ||
| return c.runToken(server, addr, rawToken) | ||
| // Certificate cannot be blindly accepted when using a trust token. | ||
| if c.flagAcceptCert { |
There was a problem hiding this comment.
can we re-structure this commit to avoid needing to check the same logic twice and duplicating the error message?
| @@ -2763,7 +2763,7 @@ test_clustering_image_refresh() { | |||
| LXD_DIR="${LXD_REMOTE_DIR}" lxc config set core.https_address "10.1.1.104:8443" | |||
|
|
|||
| # Add remotes | |||
| lxc remote add public "https://10.1.1.104:8443" --accept-certificate --token foo --public | |||
| lxc remote add public "https://10.1.1.104:8443" --accept-certificate --public | |||
There was a problem hiding this comment.
Can we add tests for not being able to use --accept-certificate with tokens please?
|
Moving to draft until I address all of the above comments. |
This PR prevents
--accept-certificateto be used with a trust token. Whenever the token is provided, the fingerprint from the token is compared to the remote certificate fingerprint.In addition, validation for mutually exclusive flags is added, more specifically trust token cannot be used with public remotes or when auth-type is OIDC.
Finally, two minor fixes; do not stop interactive mode on wrong input, and do not fail if remote is already trusting us.
Closes #13973
Closes #13891